Heartbleed bug exposes OpenSSL installations

On April 7, the OpenSSL project issued an advisory about a security vulnerability with significant implications: it allowed remote attackers to read the contents of program memory on a connected OpenSSL client or server. The "Heartbleed" bug, while it only affects a few OpenSSL releases, is noteworthy because of how widespread the affected installations are—and because the information it can expose to attackers can cause serious problems for users.

The bug affects versions 1.0.1 through 1.0.1f and betas for 1.0.2 of OpenSSL. Version 1.0.1, released in 2012, introduced support for the TLS heartbeat extension (RFC 6520), and it is the heartbeat code that contains the vulnerability. The extension is a lightweight protocol designed to let a TLS implementation check whether or not a peer is still up and running; it defines a simple message and response format for peers to exchange periodically.

The bug

Cryptographer Matthew Green (among others) has written a concise explanation of the bug in OpenSSL's heartbeat code. Essentially, a HeartbeatRequest message (by definition) includes a payload of arbitrary content—and, importantly, arbitrary length—put in by the sender. The recipient of the HeartbeatRequest must echo the same content back to the sender in its HeartbeatResponse message—returning the correct payload is, in theory, proof that the recipient is still alive and functioning correctly.

The problem is that OpenSSL does not check that the payload length listed in an incoming HeartBeatRequest is the same as the actual size of the payload supplied before it copies the payload into its HeartbeatResponse message. As a result, if the remote sender claims that it has sent a 64KB payload but in fact supplies a smaller (or a empty) payload, OpenSSL copies 64KB of memory from the starting address into the response message. The contents of that 64KB of memory could include a wide variety of sensitive things OpenSSL has seen during the current session, including private keys, username/password pairs, session identifiers, and possibly even the content of encrypted messages. Because heartbeat payloads are not logged, an attack that reveals sensitive information does not leave a trace on the victim's system.

Furthermore, because the TLS endpoint responds to all heartbeat requests, an attacker can repeatedly send specially crafted requests and collect sensitive information in 64KB chunks. Thus, although the bug itself is a simple bounds-checking error, it can potentially expose sensitive encryption material and user account data in bulk for a popular server running an affected OpenSSL build.

And, indeed, there do appear to be quite a few such affected OpenSSL builds in the wild. The Heartbleed.com site set up to publicize the vulnerability claims that up to 66% of public web sites could be vulnerable, given that OpenSSL is used by both Apache and nginx and the fact that OpenSSL 1.0.1 was the first release to introduce support for TLS versions 1.1 and 1.2. The actual numbers, of course, are probably lower, but the site notes that several popular distribution releases (Ubuntu 12.04 LTS, Fedora 18, OpenSUSE 12.2, Debian Wheezy, and CentOS 6.5) shipped affected OpenSSL packages.

A number of popular web services have been shown to be vulnerable, including Yahoo, Imgur, OKCupid, StackExchange, EventBrite, and many more. Those not interested in probing remote servers for the flaw the clunky, old-fashioned way even have a convenient web app available to do it for them. Apart from commercial services, of course, there is also the issue of cloud-based servers. On that front, Amazon published a statement outlining which Amazon Web Services (AWS) components were affected—a list that includes Elastic Load Balancing, some EC2 instances, and some OpsWorks instances.

But servers alone are not vulnerable; all OpenSSL installations, including clients, are also open to exploit by the bug, so users are encouraged to update laptop and desktop machines as well. The picture is not as clear for embedded systems; as Bruce Schneier notes:

As Sean Cassidy explained in his diagnosis of the bug, what information is exposed to rogue heartbeat requests depends on the memory allocation pattern. The memory in question is more likely to contain document data than secret keys, he said, a position also espoused by one of the bug's original discoverers, Google's Neel Mehta. Nevertheless, Cassidy said, there are reports of key data being revealed. Considering how easy the bug is to test for on public servers, perhaps that is no surprise.

The fix(es)

The bug was officially designated CVE-2014-0160 in the Common Vulnerabilities and Exposures database. It was reported to the OpenSSL team before it was announced publicly, but there is no way to tell how many systems have been compromised.

OpenSSL released an update numbered 1.0.1g on April 7 that fixes the bug. The fix involves checking the size of the heartbeat request payload against its reported length in the request message, and it blocks requests with zero-length payloads entirely. The project also explained how to deactivate the TLS heartbeat feature, an action which is sufficient to protect vulnerable machines that can live without the heartbeat functionality for the time being. Unfortunately, deactivating the heartbeat functionality does require recompiling OpenSSL with the -DOPENSSL_NO_HEARTBEATS switch, so it is not a trivial matter that can be handled with a runtime flag.

As can be seen in our vulnerability entry, most Linux distributions have now pushed out updated OpenSSL packages. Of course, those updates are generally limited just to distribution releases still receiving official security updates. Fedora, for instance, released updates for both Fedora 19 and Fedora 20, but cautioned that Fedora 18—which is also vulnerable to the bug—no longer receives updates.

The speed with which the distributions picked up on the vulnerability and pushed out updated packages is also remarkable in light of the fact that the distributors do not seem to have been alerted about the bug in advance. As a thread on the oss-security mailing list indicates, Red Hat, Ubuntu, Debian, and SUSE all reported that they first heard about the bug when it was announced to the public. Of course, given the potential impact of the bug and the length of time that vulnerable OpenSSL packages have been deployed, it could be argued that publicizing the bug widely as soon as possible was the correct action to take. Nevertheless, since Linux and BSD systems account for the lion's share of OpenSSL systems in the field, one would hope that the community could do better.

The heart of the matter

In addition to package updates, the other major cost imposed by the bug—and ultimately, perhaps the bigger cost—is the potentially exposed user data. Users of vulnerable systems may have had private keys, passwords, and other account credentials revealed to multiple unknown parties; restoring security for those users means updating account information, regenerating key pairs, and other such work, some of which (like updating SSL certificates) can be expensive. For information like message content that may have been exposed, however, there is no fix. Secret meetings in dark alleyways can be rescheduled, perhaps, but emails with unflattering descriptions of one's in-laws, once revealed, are out there for good.

That is arguably the most significant dimension to the Heartbleed story. The bug was not a flaw in an encryption algorithm or a subtle timing attack, it was a simple mistake. But, unlike the simple mistakes in the GnuTLS certificate validation vulnerability and Apple's session-key validation bug, this bug can be used to discover a lot of user account information, and to do so quickly.

That, in turn, means that it makes the operator of a vulnerable server look bad in a great many more eyes, and so it becomes a bigger news story. Of course, it is also rare for a single security bug to be given its own web site, much less a catchy name and a logo, events which might have also contributed to the speed with which the bug was relayed in the general media. But it is also a reminder that the scope of a bug is ultimately measured by the number of people it affects, not by the seriousness of the programming error at the root of the flaw. And a bug that is easily leveraged to reveal information belonging to multiple accounts on public servers affects a great many people who may otherwise pay little attention to TLS.